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REMARKS/ARGUMENTS 

Claims 1-18 and 20-22 are pending of which claims 1, 5, 10, 14, 18 and 20-22 are 
independent. Claims 1-5, 10, 14, and 18 have been amended. Claim 19 is canceled. New claims 
20-22 are added. 

Claim 19 was rejected under 35 USC §112, second paragraph, for indefmiteness. Claim 
19 is canceled. 

New claims 20-22 are supported throughout the specification and claims and, for 
example, in figures 3 and 4 of the application and in the written description of these figures on 
pages 10, 11 and 12 of the specification. 

Claims 1-19 were rejected under 35 USC § 102(e) as being anticipated by Ash (U.S. 
Patent No. 6,590,867). 

Ash: 

Ash is directed to a technique for routing calls in an IP network. (Ash, col. 1, lines 6-7.) 
According to the method of Ash, the routers exchange messages to identify available paths 
between the origin and the destination. (Ash, col. 1, lines 64-66.) First, the class of service of 
the call is determined. (Ash, col. 1, line 67 to col. 2 line 1.) Then, a path is selected that has a 
minimum cost, such as for example a minimum number of hops. (Ash, col. 2, lines 2-3.) Then, 
a check is made by a bandwidth broker of the selected path as to whether the links forming the 
path have bandwidth capacity, that is not reserved for other services, and is sufficient for the 
class of service of the call. (Ash, col. 2, lines 3-9.) If the links along the selected path have the 
requisite capacity, the router routes the packets through the selected path. (Ash, col. 2, line 10- 
11.) Otherwise, another path is selected and the step of determining whether the links along the 
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path have the requisite capacity, or depth, is repeated. (Ash, col. 2, lines 11-12.) After an 
allowed path is found, then the packets are routed over the allowed path. (Ash, col. 2, lines 13- 
16.) 

In Ash, available bandwidth, or load state, of all the links of the network is reported to the 
bandwidth broker. (Ash, col. 4, lines 2-5.) A link may be considered busy, reserved, heavily 
loaded or lightly loaded based on its load state. (Ash, col. 4, lines 7-26.) Then, depending on the 
relationship between the bandwidth in progress of the call and the bandwidth required of the 
virtual network of links to meet the blocking or loss of call probability for the call, the links with 
some of the load states, are allowed and links with other load states are not allowed to be part of 
the path of the data. (Ash, col. 4, line 40 to col. 5, line 5.) Both bandwidth in progress of a call 
and blocking probability of a network are a function of the class of service of the call. (Ash, col. 
3, lines 6-10 and lines 29-33.) For example if the bandwidth in progress, or the required 
bandwidth for the call, is smaller than double the bandwidth required of the virtual network to 
meet the blocking probability for the specific grade of service of the call, then links of all load 
states except for the completely busy links are allowed as part of the path. (Ash, col. 4, lines 60- 
64.) Conversely, if the bandwidth in progress of a call is larger than double the blocking 
bandwidth of the virtual network, then only lightly loaded links are allowed to be part of the 
path. (Id.) If a selected path does not have the required depth of service, another path is selected 
and the same determination is carried out to see whether this other path has the required depth of 
service or bandwidth availability. (Ash, col. 5, lines 20-24.) The criteria for choosing the paths 
is disclosed as the number of hops. (Ash, col. 5, line 14.) So, the path with the shortest number 
of hops, i.e. fewest links, is selected and then it is determined whether the selected path has 
sufficient depth of service/available capacity to carry the call. 
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In summary, Ash chooses between paths based on the load state of the links along the 
path. It may even select a first choice path that includes links of all levels of capacity and an 
alternate path that is longer but includes links of higher capacity. (Ash, Table III, col. 4, lines 
36-37, col. 5, lines 1-5.) Either way, a path is selected by examining the data regarding the links 
included in the path and based on determining whether all the links in the path have sufficient 
capacity for performing the service that is requested of the path and deliver the required quality. 
There is no summarized or synthesized link data that is classified as path data that would enable 
the bandwidth broker to compare path 1 versus path 2 without going to the link level data . 
Therefore, as the network gets larger and the number of links along a path increases, the testing 
to be done by Ash consumes more computing power. Further, if some of the links fail to have 
sufficient capacity, then another path is selected and tested the same way, but the first path 
cannot be modified to fit the capacity requirement . In other words, the capacity of the links is 
not negotiable and it is not assigned by the bandwidth broker. The links either have the requisite 
capacity or they don't. 

Claim 1: 

Claim 1 is amended to recite "A method for allocating bandwidth within a network 
domain by a network server operably coupled to a network domain edge node and to a database, 
the network domain including links for connecting two nodes, the method comprising: accessing 
the database , the database including path-level data comprising Quality of Service (QoS) 
information for paths, the paths including a plurality of links for connecting two edge nodes, and 
link-level data comprising QoS information for the links, the path-level data being summarized 
from the link-level data; receiving from the network domain edge node a flow request for a 
requested path ; satisfying the flow request using the path-level data if the network server 
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determines the network server can satisfy the flow request using the path-level data; and 
satisfying the flow request using the link-level data if the network server determines the network 
server cannot satisfy the flow request using the path-level data. " (Emphasis added.) Support for 
these amendments is found throughout the application and for example in the last paragraph on 
page 7 of the specification that states: "At the path-level, the bandwidth broker maintains QoS 
state information regarding each path of the network domain, which is extracted and 
'summarized' from the link QoS states of the links of the path." 

Ash goes directly to the link-level data of a path and there is no "path-level data being 
summarized from the link-level data" disclosed or suggested by Ash. As such, Applicants 
submit that claim 1 is not anticipated by Ash. 

The Office action refers to column 2, lines 1-16 of Ash for disclosing that a request is 
satisfied using path level data and if it cannot be satisfied another path is selected and the link 
level data of the second path is used to satisfy the request. This is true. However, as explained 
above, there is no path level data in Ash and Ash goes directly to the link-level data the first time 
as well. It selects the shortest path (fewest hops); verifies if the links in the path have sufficient 
available capacity based on the link-level data of the path; if not, moves to the next path and goes 
down to the link-level data of the second path as well. There is only one level of data in Ash: 
link level. 

Claims 2-4 depend from claim 1 and are believed to be allowable based on claim 1. 

Further, dependent claim 3 recites "wherein the link-level data includes for each link 
quotas of bandwidth available to the link and being divided among the paths including the link , 
the method further comprising allocating to each link along the requested path a quota of 
bandwidth from the quotas of bandwidth available to the lin k if the requested path does not have 
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enough unused bandwidth to satisfy the flow request ." (Emphasis added.) Applicants submit 
that Ash does not disclose or suggest a quota allocation system. Moreover, Ash does not include 
"allocating to each link ... a quota of bandwidth ... if the requested path does not have enough 
unused bandwidth to satisfy the flow request." 

The Office action refers to column 3, lines 6-16, 22, and 58 of Ash, for disclosing the 
quotas of claim 3. This column of Ash discloses an equivalent bandwidth needed for the call and 
a bandwidth in progress indication for the particular class of the call. Then, during a given 
period of time, a router tracks two quantities for each link, the sum of all bandwidth required for 
all flows on the link and the sum of bandwidth required for the blocked flows on the link. An 
idle link bandwidth is also kept that determines the load state of a link. A routed call, seems to 
take up any part of the idle or available bandwidth of a link that it requires irrespective of 
whether this bandwidth is allocated to the particular path of the call. In other words, the routed 
call of Ash does not appear to wait for the bandwidth broker to perform an "allocating to each 
link along the requested path a quota of bandwidth from the quotas of bandwidth available to the 
link," of claim 3. 

Claim 5: 

Claim 5 is amended to recite "providing a plurality of path- level databases ... including 
path-level data ... providing a link-level database ... the link-level database including link-level 
data ... the path-level data being summarized from the link-level data ." (Emphasis added.) As 
explained above, Ash discloses only one level of data and, to make its routing decisions, goes 
directly to the same link-level data every time. As such, Applicants submit that claim 5 is not 
anticipated by Ash. 

Claims 6-9 depend from claim 5, and are believed to be allowable based on claim 5. 
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Claim 10: 

Claim 10 is amended to recite "a database including path-level data ... for each path 
within the network domain and link-level data ... for each link within the network domain, the 
path-level data being summarized from the link- level data." As explained above regarding claim 
1, Ash discloses only one level of data to be used by the router. As such, Applicants submit that 
claim 10 is not anticipated by Ash. 

Claims 11-13 depend from claim 10, and are believed to be allowable based on claim 10. 

Claim 14: 

Claim 14 is amended to recite "accessing a database including path-level data ... and link- 
level data ... for a path within the network domain, each path comprising a plurality of links, the 
path-level data being summarized from the link-level data of the links of each path." As 
explained above regarding claim 1, Ash discloses only one level of data to be used by the router. 
As such, Applicants submit that claim 14 is not anticipated by Ash. 

Claims 15-17 depend from claim 14 and are believed to be allowable based on claim 14. 

Claim 18: 

Claim 18 is amended to recite "A method for allocating bandwidth within a network 
domain by a bandwidth broker operably coupled to a network domain edge node, comprising: 
accessing a network QoS state database operably coupled to the bandwidth broker, the network 
QoS state database including: path-level data for a path within the network domain, the path 
level data including unused bandwidth allocated to the path : a set of critical links along the path; 
and a path state; and link-level data for links along the path , the link level data including QoS 
information for links within the network domain; quotas of bandwidth available to a link ; and a 
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link state; receiving a flow request for the path; satisfying the flow request using the unused 
bandwidth if the path is not in a critical state and the path has enough unused bandwidth to 
satisfy the flow request; allocating to each link along the path a quota of bandwidth from the 
quotas of bandwidth available to the link if the path is not in a critical state and the path does not 
have enough unused bandwidth to satisfy the flow request; and allocating bandwidth to each link 
in the set of critical links from unused bandwidth reclaimed from another path on each link if the 
path is in a critical state." As explained above regarding claim 1, Ash discloses only one level of 
data to be used by the router and does not disclose allocating quotas. As such, Applicants submit 
that claim 1 8 is not anticipated by Ash. 

Claim 20-22: 

New claims 20-22 are distinguished from Ash for reasons similar to those argued 
regarding claims 1 and 3. 

Therefore, in view of the above amendment and remarks it is submitted that the now 
pending claims are patentably distinct over the cited reference and that all the rejections to the 
claims have been overcome. As such, allowance of the above Application is requested. 



Respectfully submitted, 

CHRISTIE, PARKER & HALE, LLP 
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